1. Technical Field
The present invention relates to firmware and in particular to system and methods for communicating between firmware written for different instruction set architectures.
2. Background Art
Firmware refers to processor routines that are stored in non-volatile memory structures such as read only memories (ROMs), flash memories, and the like. These memory structures preserve the code stored in them, even when power is shut off. One of the principle uses of firmware is to provide the routines that control a computer system when it is powered up from a shut down state, before volatile memory structures have been tested and configured. The process by which a computer is brought to its operating state from a powered down or powered off state is referred to as bootstrapping. Firmware routines may also be used to reinitialize or reconfigure the computer system following various hardware events and to handle certain platform level events like system interrupts.
The bootstrapping process typically begins with the processor(s) in a computer system and proceeds outward to system level resources. Initially, each processor tests its internal components and interfaces. In multiprocessor systems, a single bootstrap processor (BSP) is usually selected to handle initialization procedures for the system as a whole. These procedures include checking the integrity of memory, identifying and initializlng other resources in the computer system, loading the operating system into memory, and initializing the remaining processors. Since volatile memory structures such as caches and random access memory (RAM) are not dependable until later in the boot process the processor implements some of its early firmware routines for the various bootstrapping procedures inside nonvolatile memory.
Firmware is typically written in assembly language. This is a low level computer language that provides direct access to processor hardware and, consequently, is closely tied to the processor architecture. The processor architecture is reflected in the rest of the platform, in part, because of the assembly level firmware that is used to initialize, configure, and service platform level resources. For example, platform resources may transfer data through specified registers and/or memory locations defined by the Instruction Set Architecture (ISA), and platform level interrupts may be handled by referring to specified processor registers. Thus, initialization and configuiration of platform level resources are tied to the ISA of the underlying processor. These ties between assembly level firmware and the ISA also mean that the firmware can not be converted to different ISAs without extensive rewriting.
The ISA-specific nature of firmware is significant for processors that support more than one ISA. For example, the Merced.TM. processor is the first of a line of processors designed by Intel.RTM. Corporation of Santa Clara, Calif. to implement an Intel Architecture 64-bit ISA (IA-64). These IA-64 processors also include resources to execute programs coded in an Intel Architecture 32-hit ISA (IA-32). While the Merced.TM. processor and its progeny support IA-32 instructions, they are not IA-32 processors. Among other things, their register structures, memory addressing schemes and buses reflect their native IA-64 architecture rather than the legacy IA-32 architecture.
The IA-64 platform is new, and consequently, there are relatively few resources designed specifically for the IA-64 platform. On the other hand, there is a wealth of resources available for- IA-32 platforms, including mass storage media controllers, keyboards, mice, monitors, peripheral devices, and the IA-32 firmware that supports them. Huge investments have also been made in IA-32 firmware for newer technologies such as Advanced Configuration And Power Management Interface (ACPI), Wired For Management (WFM). In addition, compression technology is available to significantly reduce the space required to store IA-32 firmware. Approximately 1 Megabyte ("Mbyte") of firmware code may be compressed to approximately 512 Kilobytes (Kbytes), using this IA-32 firmware. Supporting these legacy resources and firmware technologies on the IA-64 platform would allow developers to preserve the investments they have already made in the IA-32 platform and reduce the time to market of IA-64 systems.
Supporting legacy firmware (IA-32) on a new processor architecture (IA-64) is a relatively complex undertaking. For example, in addition to the obvious differences in register sizes, and addressable memory, there are multiple addressing modes in the IA-32 ISA that are not present in the IA-64 ISA. IA-32 employs a mode called protected mode to increase the addressable memory size from 1 megabyte to 4 gigabytes. The present invention addresses these and other issues associated with the support of legacy firmware in a different native environment.